REMARKS 



Applicant is in receipt of the Office Action mailed June 29, 2007. Claims 1-24 
have been amended. Claims 1-29 are pending in the case. Reconsideration of the present 
case is earnestly requested in light of the following remarks. 

Telephone Interview Summary 

Applicant conducted a telephone interview with the Examiner on September 12, 
2007. Applicant discussed the cited art of Xavier. In particular Applicant noted that in 

the present application a data flow diagram executes to create a scene graph, whereas in 
Xavier an existing scene graph is added to a simulation diagram. The Examiner indicated 
that he would analyze the cited art and Applicant's claim language, and suggested that a 
second telephone interview be held on September 19, 2007, to which Applicants agreed. 
Applicant conducted another telephone interview with the Examiner on September 19, 
2007. In this second interview. Applicant reiterated the arguments mentioned above, 
particularly the distinction between using an existing scene graph and creating a scene 
graph. The arguments presented by Applicant in the Interviews are presented in more 
detail below. 

Section 101 Rejections 

Claims 1-24 were rejected under 35 U.S.C. 101 as being directed to non-statutory 
matter, specifically, for the use of "carrier medium". Applicant has amended these 
claims to refer instead to a "computer-accessible memory medium", which is statutory. 
Applicant thus respectfiiUy requests removal of the section 101 rejection of claims 1-24. 

Section 102 Rejections 

Claims 1-3, and 21-29 were rejected under 35 U.S.C. 102(e) as being anticipated 
by Xavier et al (US Pat. Pub. 2003/0079207, "Xavier"). AppUcant respectfiiUy traverses 
the rejection. 

As the Examiner is certainly aware, anticipation requires the presence in a single 
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prior art reference disclosure of each and every element of the claimed invention, 
arranged as in the claim. Lindemann Maschinenfabrik GmbH v. American Hoist & 
Derrick Co., 221 USPQ 481, 485 (Fed. Cir. 1984). The identical invention must be 
shown in as complete detail as is contained in the claims. Richardson v. Suzuki Motor 
Co., 9 USPQ2d 1913, 1920 (Fed. Cir. 1989). 

Moreover, an 'anticipating' reference must describe all of the elements and 
limitations of the claim in a single reference, and enable one of skill in the field of the 
invention to make and use the claimed invention. Bristol-Myers Squibb Co. v. Ben Venue 
Labs., Inc., 246 F.3d 1368, 1378-79 (Fed. Cir. 2001); Richardson v. Suzuki Motor Co., 
868 F.2d 1226 (Fed. Cir. 1989)." In re Merck & Co., Inc. v. Teva Pharm. USA, Inc., 347 
F.3d 1367, 1372 (Fed. Cir. 2003). 

Claim 1 recites: 

1 . A computer-accessible memory medium comprising program instructions 
for creating a scene graph, wherein the program instructions are executable to implement: 

creating a data flow diagram in response to input, wherein said creating 
comprises: 

displaying a first plurality of nodes on a display, wherein each of the 
plurality of nodes is executable to create at least a portion of the scene graph; 

connecting the first plurality of nodes to create the data flow diagram, 
wherein the first plurality of nodes are connected to specify data flow among the plurality 
of nodes; and 

executing the data flow diagram, wherein said executing creates the scene graph; 
wherein the scene graph specifles a plurality of objects and relationships between 
the objects, and wherein the scene graph is usable in rendering a graphical image of the 

plurality of objects. 

As Xavier makes clear in the Abstract and elsewhere, Xavier is directed to a data- 
flow based simulation, where different modules represent and simulate objects and their 
interactions. In contrast, in Applicant's claim 1, a data flow diagram is created that, 
when executed, creates (i.e., builds) a scene graph, i.e., a new scene graph. In other 
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words, the data flow diagram executes to create or build a data structure, and fills or 
populates the data structure with data, where the populated data structure then encodes or 
specifies the visual representation of a scene, the populated data structure being referred 

to as a scene graph. 

Nowhere does Xavier disclose creating a data flow diagram in response to 
input, wlierein said creating comprises: displaying a first plurality of nodes on a 
display, wherein each of the plurality of nodes is executable to create at least a 
portion of the scene graph, as recited in claim 1. 

Cited Figures 1, 4, 5, and paragraphs 24, 27, and 57, disclose data-flow based 
simulation, but fail to disclose nodes that are executable to create at least a portion of a 
scene graph. 

For example. Figure 1 is a diagram illustrating a conventional data-flow-based 
modular simulation of an exemplary robot arm. 

Figure 4 illustrates a data-flow-based modular simulation of an exemplary system 
including sensors and a sensor world model. Each module in the system is considered a 
proxy for, i.e., represents or simulates, a corresponding entity. 

Figure 5 illustrates an exemplary meta-module. More specifically. Figure 5 
illustrates "a representation of an individual mobile robot modeled as an Umbra 
embodied agent meta-module", which, again, is a simulation module for simulating a 
mobile robot. 

Paragraph [0024] is directed to simulations of systems or phenomena that include 
a large and/or undetermined number of devices or components, where each simulation 
module includes multiple I/O for connecting to each of the other modules in the 
simulation. 

Paragraph [0027] describes a more sophisticated approach to interconnecting 
simulation modules, specifically, using a switching module to configure I/O among 
modules, thereby reducing a quadratic number of connections to a linear number. 
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Paragraph [0057] discloses communication modules for the simulation that model 
various communication mechanisms and dependencies among the devices or components 
being simulated. 

As may be seen, none of the cited portions of Xavier teach or suggest nodes that 

are executable to create or generate (at least a portion of ) a scene graph. In other words, 

none of the modules described in Xavier are described as being executable to create or 

generate a portion of a scene graph. In fact, the only mention Xavier makes of a scene 

graph at all is in paragraph [0035], which reads as follows: 

[0035] In exemplary Umbra embodiments multiple worlds are common. 
Examples of Umbra worlds include a radio communications world, 
various sensor/sensing worlds, terrain-based mobility dynamics world, and 
a multi-body contact dynamics world. In addition, Umbra scene-graph 
used by an Umbra visualizer may typically be integrated into Umbra 
simulations as part of a world module. 

Applicant respectfully notes that according to Xavier, a scene-graph may be 
integrated into the simulations, e.g., as part of a world module, but Xavier is silent 
regarding generation of the scene graph, and never describes or even hints at nodes or 
modules in a data flow diagram that are executable to create or generate a scene graph. 

Thus, Xavier fails to teach or suggest these features of claim 1. 

Nor does Xavier disclose executing the data flow diagram, wlierein said 
executing creates tlie scene grapli; wlierein tlie scene grapli specifies a plurality of 
objects and relationships between the objects, and wherein the scene graph is usable 
in rendering a graphical image of the plurality of objects, as recited in claim 1. 

Cited paragraph [0037] discloses interconnecting simulation modules using 
conventional means, i.e., n*n connections (quadratic) among n modules, and using a 
switching module to configure I/O among modules, thereby reducing a quadratic number 
of connections to a linear number. 

Paragraph [0040] discusses including world modules in data-flow graph. 
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Paragraph [0050] is directed to the use of various "collision detection" 
technologies or libraries to determine with simulation objects/modules interact. 

Cited Figure 7 illustrates a simulation of mobile robots, but is never describes as 
being a screenshot, e.g., an actual rendering of the simulation objects. In other words, 
while Figure 7 illustrates the simulation, it is not described as the result of rendering a 
scene graph. For example, Applicant notes that the polygons mentioned are required for 
collision detection, and may or may not be used to render an image of the simulation. 
However, Applicant further notes that paragraph [0035], quoted above, does mention a 
visualizer using a scene graph that has been integrated into a world module in the 
simulation, which suggests using the scene graph to generate an image of the simulation; 
however, as discussed above, the scene graph of Xavier is not generated by executing 
nodes in a data-flow diagram. Rather, in Xavier, the scene-graph is added to a simulation 
module in the simulation, specifically, a world module. 

Nowhere do these cited portions of Xavier (nor Xavier in general) teach or 
suggest executing a data flow diagram that creates a scene graph, where the scene graph 
specifics a plurality of objects and relationships between the objects, and where the scene 
graph is usable in rendering a graphical image of the plurality of objects. 

Applicant respectfully notes that since Xavier clearly distinguishes between the 
data-flow simulation diagram described and a scene graph (see paragraph [0035]), it 
would be improper and technically incorrect to assert and equivalence between the two. 
Moreover, nowhere does Xavier disclose or even mention rendering a graphical image of 
the plurality of objects represented by the simulation diagram. 

Thus, Xavier also fails to disclose these features of claim 1 . 

Thus, for at least the reasons provided above. Applicant submits that Xavier fails 
to disclose all the features and limitations of claim 1, and so claim 1 and those claims 
respectively dependent therefrom, are patentably distinct and non-obvious over the cited 
art, and are thus allowable. 

Claims 25, 28, and 29 include similar limitations as claim 1, and so the above 
arguments apply with equal force to these claims. Thus, for at least the reasons provided 
above, Applicant submits that claims 25, 28, and 29, and those claims respectively 
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dependent therefrom, are patentably distinct and non-obvious over the cited art, and are 
thus allowable. 

Removal of the section 102 rejection of claims 1-3, and 21-29 is eamestly 

requested. 

Applicant also asserts that numerous ones of the dependent claims recite further 
distinctions over the cited art. However, since the independent claims have been shown 
to be patentably distinct, a further discussion of the dependent claims is not necessary at 
this time. 
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CONCLUSION 



Applicant submits the application is in condition for allowance, and an early 

notice to that effect is requested. 

If any extensions of time (under 37 C.F.R. § 1.136) are necessary to prevent the 
above-referenced application(s) from becoming abandoned, Applicant(s) hereby petition 
for such extensions. The Commissioner is hereby authorized to charge any fees which 
may be required or credit any overpayment to Meyertons, Hood, Kivlin, Kowert & 
Goetzel P.C., Deposit Account No. 50-1505/51 50-8300 1/JCH. 

Also filed herewith are the following items: 
I I Request for Continued Examination 
I I Terminal Disclaimer 

r~l Power of Attorney By Assignee and Revocation of Previous Powers 
r~l Notice of Change of Address 
□ Other: 

RespectfiiUy submitted, 

/Jeffrey C. Hood/ 

Jeffrey C. Hood, Reg. #35198 
ATTORNEY FOR APPLICANT(S) 

Meyertons, Hood, Kivlin, Kowert & Goetzel PC 

P.O. Box 398 

Austin, TX 78767-0398 

Phone: (512) 853-8800 

Date: 2007-09-20 JCH/MSW 
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